@martinjt can we configure live-check to ensure the telemetry schema is always up to date?

I just don't want that to be another burden for maintainers.

Also, the k8s manifests shouldn't be part of this PR. That is generated via helm update whenever we have a new release

We can, i just didnt want to make it part of this PR since its already got a lot of moving parts.

I can remove the k8s bits.

This PR was marked stale due to lack of activity. It will be closed in 7 days.

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@martinjt I had a chat with @puckpuck in the last SIG meeting and we were discussing this PR.
As an OTel user, I couldn't understand why would we run the documentation as part of the Demo.

Shouldn't we keep this PR just with the /telemetry-schema and have the telemetry docs as part of the https://opentelemetry.io/docs/demo/ docs?

Something like how the semconv docs is currently done.

My view is that we need to show people how to use Weaver for the things it's built for (Markdown documentation, and telemetry validation). The easiest of those to see is generating markdown. We show them how that's done in this repo, not be having another repo generate them and display them.

If this repo had to have something else host the docs, that wouldn't be something that people could clone, run and iterate on. We need to show people how they can use weaver, give them a place to test it, just like we do with all the languages and their instrumentations.

It's totally valid that the otel docs could ALSO use the schema to generate some more docs that are static and updated on a specific schedule. The repo, the helm chart and the images, should be able to run to allow the user to see all of them together, it shouldn't be that I run the demo, then consult the otel website for the docs (which could be for a different version).

As an application developer, I would likely have a way of viewing the changes of the documentation, I'd maybe have something in my pipeline generate github pages. Either way, it's local to the repo and something that a developer can generate

What if we keep the doc service as a different docker compose file? This would allow users to test weaver, but the docs services wouldn't always start with the Demo.
I've added an entry to discuss this at the SIG meeting tomorrow (Wed 14 Jan). (I won't be able to attend it, but happy to accept whatever is agreed by the majority).

This PR was marked stale due to lack of activity. It will be closed in 7 days.

This PR was marked stale due to lack of activity. It will be closed in 7 days.

This PR was marked stale due to lack of activity. It will be closed in 7 days.

The committers listed above are authorized under a signed CLA.

• ✅ login: julianocosta89 / name: Juliano Costa (080d9ba, 4337a67, 968f368, b4a0ceb, 099a946, 15f9fb0, 3db8ea9, 5417d1b, 5abbcc5, 85d8dbd, 8816e3e, 9962860, e0853c9, e1ecc2d, f0332be)
• ✅ login: martinjt / name: Martin Thwaites (138865e, c0a83ba)
• ✅ login: puckpuck / name: Pierre Tessier (073243e, 0df3535, 12d0939, 18a38e8, 597a724, 65f304f, aee9e31, ca4e9b5, e9e9ca7)

@julianocosta89 @ps48 I've pushed an update to this PR that:

• Upgrades Weaver from v0.21.2 to v0.22.1 and migrates the schemas to the v2 definition format (file_format: definition/2)
• Attribute files now use the flat v2 attributes: syntax with key: instead of nested groups:
• Service files use v2 attribute_groups: with visibility: public
• Renamed registry_manifest.yaml → manifest.yaml (old name is deprecated in v0.22)
• Updated the jq filters in weaver.yaml to handle the new resolved registry ID format

Also addressed the review comments:

• ✅ Added TELEMETRY_DOCS_HOST/TELEMETRY_DOCS_PORT to docker-compose.minimal.yml so the envoy template resolves correctly
• ✅ Fixed readme.md.j2 — removed the common.yaml reference, updated to reflect actual file structure (manifest.yaml, attributes/*.yaml, services/*.yaml, metrics/*.yaml)
• ✅ Updated mkdocs.yml site_url to http://localhost:8080/telemetry/
• The type inconsistencies (string vs double for amounts/costs) are noted and can be addressed in a follow-up PR

Everything builds and serves correctly with the static nginx setup.

@martinjt can you check the easyCLA issue?
It may be related to claude being a co-author of the PR

That should be done now @julianocosta89

@martinjt I ran weaver registry resolve and got a couple of messages:

⚠ Invalid attribute definition detected while resolving '"model/metrics/
  │ product_reviews.yaml"' (group_id='metric.product_reviews.ai_assistant',
  │ attribute_id='product.id'). Missing stability field.

I've added stability to the metrics (97abcc7 and bumped semconv to 1.40).

Now I'm only getting:

⚠ File format `definition/2` is not yet stable: model/services/***

But I guess this is expected.